home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Almathera Ten Pack 3: CDPD 3
/
Almathera Ten on Ten - Disc 3: CDPD3.iso
/
fish
/
726-750
/
744
/
autorunner
/
autorunner.doc
< prev
next >
Wrap
Text File
|
1995-03-18
|
12KB
|
243 lines
AutoRunner -- copyright (©) 1991 by Jon Maxwell
-----------------------------------------------
Version 2.0
Distribution:
This program is Freely distributable. It is NOT Shareware, and it is
NOT Public domain. What I mean is this: You can freely distribute it,
following the rules below. You don't have to pay money, but I would like
it very much if you do. It's NOT Public Domain because I want the rights
to the program. It's NOT Shareware because I don't think it's high enough
quality for that. (I KNOW it isn't, even though it is indispensible for
only-floppy users)
These are the distribution rules:
1) It may not be sold for profit. This includes merely being PART OF a
disk or anything else distributed for profit. This does NOT apply
to Fred Fish (his disks aren't profit ones anyway, but..).
2) The contents of the Archive MUST NOT BE CHANGED (except by Fred Fish).
This includes altering the contents, removing parts, and adding
parts, etc.
Disclaimer:
I herby declare that I will accept no responsibility for damage caused
by this program. Not even if it was used Properly. In other words, use it
at your own risk; I'm not trying to scare you off or anything, just
protecting myself in the unlikely event that somebody's data or other
things might get trashed by my program, and then them wanting to sue me.
I have found nothing wrong with it.
Intro:
You accidentally type endcli on your only CLI. You don't have workbench
running. Then you decide that you want to boot up your terminal program.
"Sh!t," you say, thinking of the minutes upon minutes it takes to boot up
from your floppy drives. You think: "[expletive]! WHY CAN'T I JUST PUT THE
DISK IN AND HAVE MY TERMINAL PROGRAM BOOT UP? WHY DO I HAVE TO TYPE 'RUN
NCOMM'?" That would save you from having to boot up, and wait a minute
or two. I once thought that too, and thus was this program created.
What AutoRunner is about:
This program does only this: When you insert a disk, it looks for its
special key thing (more on this later) and then it loads a program, types
a text file, or does anything else you can do from the CLI.
Have you ever noticed that the file comments just aren't used much?
Well, this program uses the comments to store information on what to do
when a disk is inserted. The "key" is just a special character(s) at the
very beginning of the file's comment.
How the Comments work:
When a disk is inserted, AutoRunner looks through that disk for a
comment(s) that begin with the letter "¿" or "¡". In case you don't know,
these are a shift-alt-M character and an alt-i. When it finds a comment
with the special character, it tries to run the rest of the comment. Thus,
a comment like this: "¿Execute Term:JRCommStart" would try to execute the
script JRCommStart on disk Term: .
The "¡" started comments have exactly one character after the "¡" that is
used to force the program to CD to the inserted disk. So, the above example
can be changed to: "¡CExecute JRCommStart." This way, you don't have to know
the name of the disk that the comment is on. More on this later.
This comment-command, however, doesn't need to be on the comment for any
particular file -- it can be on any file in the root directory. Are you
excited yet? Well, try to refrain from just jumping into the program;
there might actually be something you need to know in here!
(NOTE: The comments are executed in the order they appear on the disk. If
you have more than one comment-command then you might need to use the
LIST command to get them in the right order. This is a BUG, but it's not
so bad. I will try to fix it, but I don't have the energy now to do all that
sorting stuff.)
Usage:
From the CLI, the usage is: 1> AutoRunner ####CSO
Where the 1> is just the CLI prompt, and the #'s are what units (drives)
you want it to check for comment-commands on. Any of the #'s may be left
out, and you can skip drives, like 02 would check df0: and df2: . A 023
would check df0:, df2:, and df3: . At first, I just had it so that
you could check a range of units, like 0-1 or 0-2 or 1-3, but then I
realized that some people, like 2000 users, might have one internal drive
and one external. On the 2000, the external drive is df2:, and df1: is
just skipped (if you only have one internal and one external). The #'s,
however, are limited to 0-3 now, since that's all the units that are
currently supported by the trackdisk.device (I think).
The C, S, and O are flags. Putting a C in with the drive numbers makes
it so that the program DOESN'T CD to the disk that was just inserted.
Putting an S in make it NOT check all the chosen drives for commands when
the program starts. Putting an O makes the program only check for
comment-commands that are on the drives when the program is started. After
checking and/or executing these commands, the program will immediately exit.
Starting It:
From the WorkBench, just click on its icon. I don't know whether or
not you can change the drives that will be checked with the Workbench.
I don't think so. There is a way around it, though: You can write a
script that will run the program, and use IconX to run it. It's possible
anyway! The program is meant to be started in one's startup-sequence
anyway, so I don't think it really matters.
From the CLI, just type AutoRunner, along with the parameters (If
you don't like the defaults), and return. It can be run and also
RunBacked (see below).
The Defaults are: units 0&1 will be checked, 2&3 will not.
CD to disks, and check the drives on startup.
Running it in the Background:
AutoRunner supports being run by Runback. If you don't use runback, any
output from the program or the comment-commands will be displayed in the
CLI it was started from. If you do use Runback on the program (to free up
your CLI for EndCli-ing) then there will be no output. I had a problem
with the WorkBench loading; it didn't open any output channels, and so the
program crashed whenever it tried to write something (either a program
message or a comment-command output). The only way I could see to fix this
was to open a CLI window for the output (I tried sending it to NIL and it
didn't work for some reason). I didn't want a big ugly CLI window with my
program, though, so I resolved to make it a one-pixel (dot) CLI window. It
is located in the upper left corner, so that it you Want to see output from
the program, you can just put your pointer as far up and left as it goes
and hold down the left button and re-size it so that it's big enough to see.
This only works when it's run from the WorkBench, though.
The AutoRunner Window:
Appears in the upper left, just below the Screen title. Say that you
didn't want a disk to be searched.. maybe because you already had your
terminal program running, but wanted your terminal disk in the drive.
Well, you could close the AutoRunner window (via the Close Box), which
naturally quits the program, Or you could put AutoRunner into Sleep mode. To
do this, activate the AutoRunner window (by clicking on it), and then click
the menu button. This will change the window (and screen) title to
"AutoRunner: Sleeping" Of course, in this mode, disks aren't searched though
for comment-commands. And also, of course, to wake it up you just click
in the window and then click the menu again.
Near the right side of the window are 4 gadgets, numbered 0 through 3.
Clicking on these will re-search a disk in that drive for comment-commands.
AutoRunner Messages:
These appear mostly when AutoRunner has an error. They are:
1) "Can't Open Unit: #" -- This means just that. It can't open a unit
(drive). This should never occur except when you gave it a unit to check
that isn't there (like having it check df2: when you only have df0: and
df1:). If you use the defaults and you don't have one of the drives that
it checks by default then you will get this message.
2) "Bad Lock" -- This one is a little ambiguous. What it means is that
it couldn't get a "lock" on the root directory of a disk. Normally, this
error should be impossible. The only thing I can think of is if you have
an unformated/not dos disk that you put in. The checking is there
anyway, just in case, so that you don't get a GURU.
3) "Can't get a (shared) lock on <DRIVE>" -- Absolutely should not
ever happen, under any circumstances. If you get this message, don't
blame Autorunner if you get a GURU (AutoRunner will handle it properly,
but I _think_ it means that your system is totally screwed).
4) The only other AutoRunner message is when you put a disk in with a
comment-command. It prints the command to the CLI (or nowhere if it was
runbacked) so that you can know what is happening.
5) All other output comes from comment-commands' output.
Money:
If you decide that this program is just so useful, and you use it, then
send some money, please, to the following address. Also send any bug
reports, suggestions, comments to the address (or the BBS -- later). Now,
sending money isn't a requirement (it isn't shareware), but I spent quite
a bit of time bringing you this wonderful program, making it small (despite
my PD compiler), and stuff like that. If you just send me some money, maybe
$10, then I'll be very happy. OR, if you feel like you owe me something, but
you don't want to send money, then learn to program and/or send Commodore a
big fat donation-check (they'll appreciate it, trust me -- they NEED it!).
I stress that this IS NOT shareware, so you don't HAVE to send any money,
but if this were compiled with a REAL compiler, then it would be a lot
smaller.... and I don't have the money to get a REAL compiler (a C one maybe)
My address:
Jon Maxwell
7706 Hillview Ave.
Richmond, Virginia 23229
A BBS that I'm on:
Late Night BBS
(804)262-9944
E-Mail Scruffy
I'm resonably sure that I'll be there, and that the BBS will still be
there, but if it doesn't exist when you try to call, then just write a
letter.
Special Thanks Go To:
Tom Krehbiel, for his help with the IO messages.
Commodore (of course), for the Amiga, and for their excellence in
computer and OS design.
People who support shareware
who send money for programs that they like/use.
who buy American first (That is, people who boycott countries,
like Japan, that practice unfair trade
practices, like making it take 5 years
for foreigners to open a little store)
who re-cycle
Special No-Thanks go to:
People who don't want to learn.
I think that this about wraps it up:
I can only think of a couple more things...
1) All the files in the archive MUST remain together (no leaving out
files and re-uploading)
2) All files must be in their original condition (no changing things)
3) I guess I already said the above two...
4) Have fun, and enjoy automation and less typing to load programs!
Improvements:
1) Dispose()-ed variables. Each time a disk was inserted, it would keep
more memory. It would be released when the program ended. Now it's
released when it finished checking each disk (lowers chance of memory
fragmentation a bit, and memory doesn't get hogged by AutoRunner after
multiple disk insertions)
2) Fixed an annoying bug that "woke" the program from "sleep" when you
re-activated the window. Not really annoying unless you have a Sun
Mouse (auto activates windows when you move the pointer over them)
3) Added 0123 gadgets to allow you to easily re-load a disk's commands.
4) Changed the name from AutoRun to AutoRunner (after MenuRunner).